Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Perform unaligned writes via FFI when necessary #587

Merged
merged 19 commits into from
Sep 15, 2023

Conversation

clyring
Copy link
Member

@clyring clyring commented May 21, 2023

As noted in #184: We also perform (un-guarded) unaligned Word16 writes when performing fixed-width hexadecimal encoding, but this doesn't seem to be causing any actual problems.

Perhaps this patch should be more liberal about unaligned Word16 writes. I'd like to take a closer look at that before merging this.

@clyring clyring marked this pull request as draft May 23, 2023 01:33
clyring added 2 commits June 4, 2023 11:20
cpp-options: -Werror=undef is pulling its weight already.
@clyring
Copy link
Member Author

clyring commented Aug 30, 2023

Ah, right. Of course cabal_macros.h is not available in our emulated jobs, which don't use cabal to begin with.

Omitting the C functions when we don't actually use them on the Haskell side seems to be more trouble than it's worth.

  - Haskell unaligned write functions now live in a new module:
      Data.ByteString.Utils.UnalignedWrite
  - The word*HexFixed functions now use unaligned writes;
      likewise Data.ByteString.Builder.RealFloat.Internal.copyWord16.
  - An FFI workaround for unaligned Float/Double writes was added.
  - The data tables in Data.ByteString.Builder.Prim.Internal.Base16
      and Data.ByteString.Builder.RealFloat.{D,F}2S now live in
      the new file cbits/aligned-static-hs-data.c so that we can
      fearlessly perform aligned reads from them.
  - The static Word64 data tables are now stored in
      host-byte-order instead of always little-endian.
  - Data.ByteString.Builder.RealFloat.Internal.digit_table
      is now a static data blob instead of a CAF.
  - All CPP around castFloatToWord32/castDoubleToWord64 now
      lives in Data.ByteString.Builder.Prim.Internal.Floating.
@@ -124,24 +125,27 @@ library
NamedFieldPuns

ghc-options: -Wall -fwarn-tabs -Wincomplete-uni-patterns
-optP -Wall -optP -Werror=undef
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-optP -Werror=undef instead of -Wcpp-undef is another sacrifice to ghc-8.0 compatibility.

@clyring clyring marked this pull request as ready for review September 15, 2023 21:37
@clyring clyring requested a review from Bodigrim September 15, 2023 22:43
W64# (indexWord64OffAddr# arr i)
#endif
getWord64At :: Ptr Word64 -> Int -> Word64
getWord64At (Ptr arr) (I# i) = W64# (indexWord64OffAddr# arr i)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it sufficient now, without byteSwap64#?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nevermind, it's because lookup tables now automatically have correct endianness.

Copy link
Contributor

@Bodigrim Bodigrim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Insane amount of work, thanks!

@clyring clyring merged commit 16d6b7e into haskell:master Sep 15, 2023
11 of 14 checks passed
clyring added a commit to clyring/bytestring that referenced this pull request Jan 30, 2024
It is poorly documented and dangerous with respect to alignment
and internal padding. It is exposed only via the semi-internal
module Data.ByteString.Builder.Prim.Internal, and has no users
on Hackage. (Since haskell#587 we do not use it internally.)
@clyring clyring mentioned this pull request Jan 30, 2024
Bodigrim pushed a commit that referenced this pull request Jan 30, 2024
It is poorly documented and dangerous with respect to alignment
and internal padding. It is exposed only via the semi-internal
module Data.ByteString.Builder.Prim.Internal, and has no users
on Hackage. (Since #587 we do not use it internally.)
clyring added a commit that referenced this pull request Feb 5, 2024
It is poorly documented and dangerous with respect to alignment
and internal padding. It is exposed only via the semi-internal
module Data.ByteString.Builder.Prim.Internal, and has no users
on Hackage. (Since #587 we do not use it internally.)

(cherry picked from commit 4508709)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants